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About  the  Technical  Note  Series  on 
Business  and  Acquisition  Guidelines 


The  Product  Line  Systems  Program  is  publishing  a  series  of  technical 
notes  designed  to  condense  knowledge  about  product  line  acquisition 
and  business  practices  into  a  concise  and  usable  form  for  the 
Department  of  Defense  (DoD)  acquisition  manager  and  practitioner. 
Each  technical  note  will  focus  on  one  aspect  of  adopting  software 
product  line  practice  in  the  Department  of  Defense.  Our  objective  is  to 
provide  practical  guidance  to  early  adopters  on  ways  to  integrate  sound 
product  line  practices  into  their  acquisitions.  By  investigating  best 
commercial  and  government  practices,  the  SEI  is  covering  new  ground 
to  overcome  challenges  and  increase  the  understanding,  maturation,  and 
transition  of  software  product  lines. 

Together,  the  technical  notes  will  lay  down  a  conceptual  foundation  for 
DoD  product  line  business  and  acquisition  practices  that  is  consistent 
with  the  SEFs  product  line  practice  framework  [Clements  99]. 

While  we  intend  each  technical  note  to  be  distributed  and  read  as  a 
standalone  document,  this  particular  technical  note  provides 
background  information  that  may  be  helpful  in  understanding  the  other 
notes  in  this  series.  Additionally,  a  brief  overview  of  software  product 
lines  is  provided  in  A  Framework  for  Software  Product  Line  Practice , 
Version  2.0  [Clements  99].  Other  information  on  product  line  practices, 
including  the  latest  version  of  the  SEI’s  Framework  for  Software 
Product  Line  Practice,  is  available  on  the  SEFs  Web  page  at 
http://www.sei.cmu.edu/activities/plp/plp_init.html. 


CMU/SEI-2000-TN-001 


v 


VI 


CMU/SEI-2000-TN-001 


Abstract 


Industrial  experience  demonstrates  clearly  that  a  product  line  approach  for 
software-intensive  systems  can  save  money  and  result  in  faster  time  to  field  higher 
quality  systems.  Many  within  the  Department  of  Defense  (DoD)  recognize  the 
benefits  of  product  lines,  but  also  recognize  that  there  are  significant  challenges  to 
adopting  this  approach.  Many  of  these  challenges  stem  from  the  fact  that  the  DoD 
is  in  the  business  of  acquiring  systems  rather  than  developing  them. 

The  Product  Line  Systems  Program  is  publishing  a  series  of  technical  notes 
designed  to  condense  knowledge  about  product  line  acquisition  practices  into  a 
concise  and  usable  form  for  the  DoD  acquisition  manager  and  practitioner. 

This  technical  note  provides  background  information  about  product  lines  to  serve 
as  a  foundation  for  other  technical  notes  in  this  series.  Key  terms,  concepts,  and 
benefits  of  a  product  line  approach  are  given.  Additionally,  concepts  of  product 
line  acquisition  in  a  DoD  context  are  discussed. 
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1  Introduction 


A  product  line  approach  to  developing  and  deploying  software-intensive  systems 
offers  great  promise  for  delivering  higher  quality  systems  in  a  shorter  time  and  at 
reduced  cost.  Documented  benefits  include  order  of  magnitude  decreases  in 
software  development  cost  and  system  integration  time.  [Bass  97,  Bass  98,  Bass 
99].  While  many  commercial  firms  and  Department  of  Defense  (DoD)  contractors 
are  already  engaged  in  product  line  practices,  most  DoD  organizations  are  still  in 
the  early  stages  of  determining  how  product  lines  can  best  be  applied  in  the  DoD 
acquisition  environment. 

While  these  DoD  organizations  have  recognized  the  benefits  of  product  lines  and 
promote  the  concepts  upon  which  they  are  built  (e.g.,  architecture-centric 
development,  open  systems,  and  systematic  software  reuse),  they  have  also 
recognized  that  there  are  several  technical  and  non-technical  challenges  to  fully 
embracing  product  lines  within  the  DoD  acquisition  environment.  Many  of  the 
non-technical  challenges  translate  directly  into  acquisition-related  issues  stemming 
from  the  DoD  acquisition  environment  itself. 

The  DoD  environment  is  based,  in  part,  upon  the  requirements  and  guidance 
specified  in  high-level  policies  and  regulations.  The  policies  and  regulations  do  not 
in  themselves  present  a  barrier  to  embracing  a  product  line  approach.  However, 
often  the  local,  cultural  interpretations  of  these  doctrines  do  present  barriers. 

Within  the  current  DoD  acquisition  environment,  it  is  not  unusual  for  major 
systems  to  require  7  to  10  years  to  progress  from  conceptualization,  through 
research  and  development,  design,  integration,  test,  to  deployment.  Most  of  these 
systems  are  structured  to  work  in  isolation — as  stand  alone  efforts.  With  such 
stand-alone  development  efforts,  the  DoD  typically  must  re-leam  many  of  the  same 
lessons  in  each  development.  Moreover,  money  is  being  expended  in  many  cases  to 
build  systems  having  common  elements  that  have  been  developed  by  other 
programs.  Currently,  the  DoD  is  not  taking  full  advantage  of  opportunities  across 
projects  to  leverage  already  developed  assets.  Such  leveraging  can  improve 
reliability  and  affords  common  operations  and  training,  not  to  mention  reduction  of 
required  funding  and  faster  deployment  times.  Another  challenge  is  the  trend  in 
staffing  and  budgeting.  Downsizing  of  the  DoD  workforce  and  shrinking  budgets 
have  placed  more  and  more  emphasis  on  the  acquisition  aspects  of  such  software¬ 
intensive  systems,  rather  than  on  “in  house”  development.  This  shift  in  emphasis 
also  applies  to  the  acquisition  of  services  for  sustaining  these  systems.  This 
movement  toward  a  leaner  workforce  has  heightened  the  need  for  a  skilled 
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workforce,  especially  for  the  acquisition  management  of  the  software  in  these 
software-intensive  systems. 

While  these  challenges  can  be  formidable,  they  are  not  insurmountable.  What  is 
needed  are  innovative  approaches  to  system  acquisitions  that  take  advantage  of  the 
guiding  principles  of  acquisition  reform,  leverage  assets  across  projects, 
compensate  for  workforce  reductions  and  budgetary  constraints,  and  enable 
deployment  of  high  quality  systems  faster  and  cheaper,  while  still  satisfying  the 
users.  Product  line  practice  offers  an  approach  that  can  help  satisfy  these  DoD 
needs,  and  there  are  several  examples  of  successful  use  of  product  lines  within  the 
DoD  [Bergey  981]. 

To  examine  the  “fit”  of  a  product  line  approach  within  the  DoD  acquisition 
environment,  we  need  to  understand  the  concept  of  a  software  product  line  and 
considerations  involved  in  commissioning  a  contractor(s)  to  develop  and  evolve 
elements  of  a  product  line.  This  technical  note,  along  with  the  software  product 
line  practice  framework  [Clements  99],  provide  background  information  about 
product  lines  to  serve  as  a  foundation  for  other  technical  notes  in  this  series.  Key 
terms,  concepts,  and  benefits  of  a  product  line  approach  are  given,  followed  by  a 
discussion  of  product  line  acquisition  concepts  in  a  DoD  context. 


1  See  also  Bergey,  John,  et  al.  Second  DoD  Product  Line  Practice  Workshop  Report 
(CMU/SEI-2000-TR-002).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie 
Mellon  University.  Expected  publication  date,  March  2000. 
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2  Software  Product  Line  Basics 


2.1  Key  Concepts 

The  field  of  software  product  lines  is  new  enough  to  offer  different  definitions  for 
similar  concepts.  The  SEI  has  derived  a  definition  from  the  hard  goods  industry 
that  brings  together  the  key  intent  of  these  sometimes-competing  definitions.  We 
define  a  product  line  as 

a  group  of  products  sharing  a  common,  managed  set  of  features  that 

satisfy  specific  needs  of  a  selected  market  or  mission  [Clements  99] 

For  example,  a  lawnmower  company  may  offer  a  number  of  riding  mowers  that 
share  a  similar  market  strategy  and  a  common  set  of  features,  but  vary  in  some 
distinct  ways.  These  products  would  be  grouped  together  and  referred  to  as  a 
product  line  of  riding  mowers.  They  would  be  marketed  as  a  product  line. 
Customers  would  come  to  recognize  the  product  line  by  name  and  select  from  the 
products  in  the  product  line  according  to  the  features  that  suit  their  individual 
needs.  From  a  manufacturing  standpoint,  all  of  the  mowers  in  the  product  line 
would  be  built  to  take  economic  advantage  of  the  features  they  have  in  common. 
They  would  share  a  common  overall  design,  common  parts,  common  tooling, 
common  manufacturing  processes,  common  quality  control  procedures,  etc. — all 
assets  in  the  mower  product  line. 

A  software  product  line  is  no  different  in  definition,  concept,  or  motivation.  It 
simply  makes  sense  to  treat  groups  of  software  products  that  have  a  common, 
managed  set  of  features  as  a  product  line.  The  best  way  to  build  a  software  product 
line  to  take  economic  advantage  of  the  features  they  have  in  common  is  for  them  to 
share  a  common  architecture  that  is  used  to  structure  components  from  which  the 
products  are  built.  The  architecture  and  components  are  central  to  the  set  of  core 
assets  (sometimes  referred  to  as  the  asset  base  or  platform )  used  to  construct  and 
evolve  the  products  in  the  software  product  line.  The  individual  products  in  the 
product  line  are  built  from  these  core  assets  according  to  a  pre-defined  production 
plan,  sometimes  called  a  reuse  guide.  Software  product  lines  provide  systematic 
reuse  of  the  core  assets. 

Since  software  reuse  is  not  a  new  concept,  how  does  product  line  practice  differ 
from  earlier,  less  successful  reuse  efforts?  Early  efforts  focused  on  small-grained 
reuse  of  software  code.  The  cost  of  creation  and  use  of  these  small-grained  assets 
often  outweighed  the  modest  gains.  Over  the  years,  reuse  technology  has  evolved 
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to  focus  on  progressively  larger-grained  assets  Today,  the  state  of  the  art  is  to  reuse 
strategic,  large-grained  reusable  assets  such  as  a  software  architectures, 
architectural  frameworks,  processes,  test  cases,  components,  and  production  plans 
to  guide  the  creation  of  products.  Using  this  more  system-focused  approach,  reuse 
can  result  in  remarkable  benefits.  Some  examples  of  these  gains  are  described  in 
the  next  section. 

2.2  Benefits  of  a  Product  Line  Approach 

A  number  of  organizations  have  already  gained  order-of-magnitude  improvements 
in  efficiency,  productivity,  and  quality  through  a  product  line  approach.  Often  even 
more  important  than  cost  savings  is  the  fact  that  product  line  practice  enables  an 
organization  to  more  rapidly  field  products  to  satisfy  operational  needs.  For  the 
DoD,  this  factor  is  key,  allowing  for  the  rapid  deployment  of  new  technologies  and 
capabilities  to  support  the  war  fighter.  As  Robert  Harrison,  Naval  Systems  Warfare 
Center,  succinctly  stated,  “The  right  answer  delivered  late  is  the  wrong  answer” 
[Bergey  98]. 

Specific  quantified  benefits  of  software  product  line  practice  have  been  reported  in 
workshops  and  case  studies  conducted  by  the  Software  Engineering  Institute 
[Brownsword  96,  Bergey  982].  For  example,  the  Swedish  naval  defense  contractor, 
CelsiusTech,  reported  a  reversal  in  the  hardware-to-software  cost  ratio,  from  35:65 
to  60:20,  that  now  favors  the  software  [Brownsword  96]  as  a  result  of  their 
software  product  line  approach  for  defense  ship  systems.  Hewlett  Packard  has 
collected  substantial  metrics  showing  two  to  seven  times  cycle  time  improvements 
with  product  line  practices.  Motorola  has  shown  a  four  times  cycle  time 
improvement  with  80%  reuse  on  their  Flexworks  pager  product  line  Cummins 
Engine  realized  a  decreased  time  for  system  build  and  integration  from  about  one 
year  to  as  little  as  three  days  in  one  case.  Among  other  organizations  that  have 
shown  efforts  yielding  equally  dramatic  product  line  results  are:  Thompson-CSF  in 
air  traffic  control  systems,  Alltel  in  commercial  bank  systems,  Ericsson,  Nokia, 
Lucent,  and  AT&T  in  telecommunication  systems,  Buzzeo  in  college  registration 
systems,  Boeing  in  airflight  software,  and  the  National  Reconnaissance  Office  in 
ground-based  command  and  control  systems  for  satellites. 

The  reported  benefits  are  compelling,  but  what  do  you  actually  do  when  you 
engage  in  a  product  line  approach?  In  the  next  section  we  describe  the  high-level, 
essential  product  line  activities. 


2  See  also  Bergey,  John,  et  al.  Second  DoD  Product  Line  Practice  Workshop  Report 
(CMU/SEI-2000-TR-002).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie 
Mellon  University.  Expected  publication  date,  March  2000. 
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2.3  Essential  Activities  of  a  Product  Line  Practice 


At  its  essence,  fielding  a  product  line  involves  core  asset  development  or 
acquisition  and  product  development  or  acquisition  using  the  core  assets 
[Clements  99].  Formally,  product  line  practice  is  defined  as 

the  systematic  use  of  software  assets  to  modify,  assemble,  instantiate,  or 
generate  the  multiple  products  that  constitute  a  product  line 


Multiple  verbs  appear  in  this  definition  because  there  are  a  variety  of  ways  in 
which  the  core  assets  can  actually  be  used  to  create  products.  The  production  plan 
would  elaborate  on  which  technique  is  to  be  used  for  a  given  product  line. 


The  activities  of  core  asset  and  product  development/acquisition  can  occur  in 
either  order,  or  (most  commonly)  in  concert  with  each  other.  Core  asset 
development/acquisition  has  been  traditionally  referred  to  as  domain  engineering. 
Product  development/acquisition  from  core  assets  is  often  called  application 
engineering.  The  entire  process  is  staffed,  orchestrated,  tracked,  and  coordinated 
by  management.  Figure  1  (Essential  Activities  of  Product  Lines)  illustrates  this 
triad  of  essential  activities.  The  iteration  symbol  at  the  center  represents  the 
decision  processes  that  coordinate  the  activities. 


Domain  Engineering  Application  Engineering 


Figure  1:  Essential  Activities  of  Product  Lines 

The  bi-directional  arrows  indicate  not  only  that  core  assets  are  used  to  develop 
products,  but  that  revisions  to  core  assets  or  even  new  core  assets  might,  and  most 
often  do,  evolve  out  of  product  development.  The  diagram  does  not  specify  which 
part  of  the  diagram  is  entered  first.  In  some  contexts,  already-existing  products  are 
mined  for  generic  assets  that  are  then  migrated  into  a  product  line.  At  other  times, 
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the  core  assets  may  be  developed  or  procured  first  in  order  to  produce  a  set  of 
products  that  is  merely  envisioned  (i.e.,  planned)  and  does  not  yet  exist. 

There  is  a  strong  feedback  loop  between  the  core  assets  and  products.  Core  assets 
are  refreshed  as  new  products  are  developed.  The  potential  value  of  the  core  assets 
is  realized  through  the  number  of  products  that  are  developed  from  them.  As  a 
result,  the  core  assets  are  typically  made  sufficiently  generic  by  considering 
potential  new  products  on  the  horizon.  Finally,  both  the  core  asset  and  the  product 
development/acquisition  are  themselves  iterative,  as  illustrated  in  Figure  1 . 

Software  product  lines  are  not  a  panacea,  but  can  have  colossal  impact  if  properly 
used.  Before  embarking  on  a  product  line  approach,  it  is  important  to  understand 
the  business  goals  and  to  develop  a  business  case  for  choosing  product  line 
practices.  It  is  also  very  important  to  carefully  scope  the  product  line.  A  product 
line  that  potentially  includes  too  many  systems  may  need  to  support  an  unwieldy 
amount  of  variation. 

In  this  section,  we  have  discussed  the  high-level  product  line  activities  in  terms  of 
both  development  and  acquisition  of  core  assets  and  products.  More  detail  can  be 
found  in  A  Framework  for  Software  Product  Line  Practice  [Clements  99].  In  the 
next  section,  we  will  concentrate  more  on  the  acquisition  aspects  of  product  line 
practice. 
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3  Product  Line  Acquisition 


3.1  Terminology 

For  the  DoD,  the  term  acquisition  can  have  several  meanings  depending  upon  the 
individuals  involved  or  the  programs  involved.  For  consistency  throughout  this 
series  of  technical  notes,  we  will  rely  on  the  definition  from  the  Federal 
Acquisition  Regulation  (FAR),  in  which  acquisition  is  defined  as 

the  process  of  obtaining  products  and  services  through  contract 

Although  acquisition  and  contracting  are  often  used  interchangeably,  acquisition  is 
really  the  process  of  obtaining  through  contract.  A  contract  is  a  binding  agreement 
between  two  or  more  parties  that  establishes  the  requirements  for  the  products  and 
services  to  be  acquired.  The  process  involves  significantly  more  effort  than  just 
contracting,  such  as  planning,  requirements  definition  and  management, 
solicitation,  and  evaluation  [Ferguson  96]. 

Another  important  concept  is  that  of  an  acquisition  strategy.  Again,  this  term  can 
have  several  interpretations.  For  our  purposes  we  define  an  acquisition  strategy  as 

a  plan  of  action  for  achieving  a  specific  goal  or  result  through  contracting 
for  products  and  services 

Acquisition  strategies  from  a  product  line  perspective  introduce  a  new  paradigm 
into  DoD  traditional  acquisition  process. 

3.2  Essential  Acquisition  Activities 

The  essential  activity  of  core  asset  acquisition,  noted  earlier,  involves 
commissioning  suppliers  or  contractors  to 

•  develop  a  software  architecture 

•  develop  a  production  plan 

•  develop  other  core  assets 

•  mine  legacy  assets  to  extract  core  assets 

•  manage,  sustain,  upgrade,  and  enhance  the  asset  base  and  support  product 
developers 

•  purchase  or  license  commercial  off-the-shelf  (COTS)  components 
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a  combination  of  the  above 


For  product  acquisition  this  involvement  includes  commissioning  suppliers  or 
contractors  to 

•  develop  a  specific  product  or  set  of  products  from  core  assets  according  to  the 
production  plan 

•  maintain,  upgrade,  or  enhance  a  product  or  set  of  products 

•  provide  new  assets  (created  during  product  development)  for  evaluation  as 
candidate  assets 

Given  these  two  essential  product  line  activities  of  core  asset  acquisition  and 
product  acquisition,  there  are  at  least  three  derived  product  line  acquisition 
activities  that  must  be  coordinated  in  the  DoD  acquisition  environment.  These 
activities  include 

1 .  acquiring  an  architecture  and  other  elements  of  an  asset  base  to  enable  a 
product  line  approach 

2.  acquiring  software  products  that  are  developed  using  this  asset  base 

3.  acquiring  the  services  to  maintain  and  sustain  the  asset  base  while  supporting 
the  development  and  enhancement  of  derivative  systems 

Additionally,  a  comprehensive  product  line  concept  of  operations  to  describe  the 
coordination  and  interplay  of  these  activities  must  be  developed  and  maintained. 

A  product  line  acquisition  program  may  be  implemented  at  various  levels — for 
example,  system,  subsystem,  or  component  level.  Traditionally,  in  following  a 
systems  engineering  process,  systems  are  decomposed  into  lower  level  systems, 
subsystems,  and  components.  This  is  what  DoD  5000. 2R  refers  to  as  “component 
breakout.”  Another  key  step  in  the  systems  engineering  process  is  the  iterative 
allocation  of  system  requirements  to  hardware  and  software.  This  allocation  also 
occurs  at  the  system,  subsystem,  and  component  level.  A  software  product  line 
approach  may  be  employed  at  one  or  more  of  these  levels,  depending  on  many 
factors  such  as  the  application  domain,  degree  of  commonality  and  feature 
variability  with  other  systems/susbsystems  components,  and  availability  of 
candidate  (reusable)  software  assets. 

To  illustrate  these  engineering  concepts,  consider  a  fighter  aircraft  as  an  integrated 
system  of  subsystems  and  components  that  perform  certain  functions  for  the 
aircraft,  such  as  navigation.  A  product  line  program  could  be  established  for  a 
computational  system  used  across  a  family  of  fighters  or  a  product  line  program 
could  be  established  for  the  navigation  subsystems  supplied  to  many  airframes. 
This  may  seem  to  complicate  the  adoption  of  a  product  line  approach  for  such 
systems.  However,  the  key  point  is  that  each  subsystem  (being  a  member  of  its  own 
product  line)  should  have  an  acquisition  program  appropriate  for  that  subsystem. 
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Using  a  product  line  implementation  approach  at  the  system,  subsystem,  or 
component  level  can  yield  significant  benefits  in  terms  of  the  time  and  cost 
required  to  field  a  product  with  proven  capability  and  predictable  quality 
attributes. 

Two  basic  product  line  system  acquisition  strategies  can  be  envisioned  within  the 
DoD  environment:  a  “top  down”  strategy,  and  a  “bottom  up”  strategy.  (Certainly,  a 
combination  of  these  strategies  can  be  used.)  The  top  down  approach  acquires  a  set 
of  core  assets  and  then  commissions  the  development  of  products  (systems)  from 
those  assets.  In  the  bottom  up  approach,  a  system  is  acquired  during  which  the 
software  architecture  and  (possibly)  other  components  are  acquired  to  be  candidate 
core  assets  for  a  product  line.  Each  strategy  has  advantages,  disadvantages,  and 
risks. 


Software  Assets 


SW  Architecture 
Component 
COTS 
NDI 

VA 

TA 

1 

i 

WA 

1 

k7j'; .  '  V  ' '  e,  /V;"'  * 

m 

Product  Line 

System  I  *  W  -  ■  ;  A 

System  2  i 
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System  3  -  y  A 
System  4  ^ 

;  w  a 

ATA  T.A 

Figure  2:  A  Product  Line  Acquisition  Program 

From  a  life  cycle  perspective,  the  Gannt  chart  in  Figure  2  (A  Product  Line 
Acquisition  Program )  illustrates  what  one  possible  product  line  acquisition 
program  might  conceptually  look  like.  Here,  core  assets  are  acquired  through  the 
acquisition  of  system  #1.  Then  each  subsequent  system  in  the  product  line  is  an 
integrated  collection  of  these  acquired  components,  COTS,  and  non-developmental 
items  (NDI).  These  assets  may  be  tracked  and  sustained  separately  from  the 
systems  subsequent  to  system  #1,  and  are  developed  to  meet  the  common  and 
variable  requirements  of  the  entire  product  line. 

Because  asset  redevelopment  occurs  less  frequently  than  system  development, 
these  assets  may  be  procured  independently  of  a  system.  As  an  example,  in  Figure 
2,  the  software  architecture  remains  stable  over  the  acquisition  of  the  first  3 
systems  and  their  different  versions.  Perhaps  due  to  changes  in  the  technical 
architecture,  the  software  architecture  is  revised  in  system  #4.  Common 


CMU/SEI-2000-TN-001 


9 


components  are  upgraded  as  allocated  functional  requirements  are  added,  such  as 
with  the  acquisition  of  system  #3.  New  COTS  components  are  procured  as  they 
change  in  response  to  market  competition. 

From  a  “systems”  point  of  view,  a  software  product  line  may  offer  significant 
economies  of  scale  at  the  appropriate  system,  susbsytem,  or  component  level  by 
providing  the  technical  infrastructure  and  software  asset  base  needed  to  exploit  the 
benefits  of  systematic  software  reuse — even  in  the  case  where  there  may  not  be  a 
standard  platform  (i.e.,  a  common  set  of  computer  hardware  resources).  The 
classical  output  of  the  software  product  line  is  a  complete  software  system 
consisting  of  a  software  architecture,  common  software  applications,  common 
software  components,  and  a  host  of  other  reused  assets  (e.g.,  requirements,  user 
scenarios,  documentation,  etc.).  In  a  scaled  down  approach,  the  outputs  of  a 
software  product  line  may  be  limited  to  producing  common  applications,  or 
common  components  from  which  applications  can  be  built. 

The  point  is  that  the  adoption  of  a  software  product  line  approach  can  have 
advantages  at  multiple  levels.  But  choosing  a  product  line  approach  will  impact 
planning  activities  at  the  program,  system,  or  subsystem  procurement  levels  and 
will  affect  the  content  of  acquisition  packages  and  other  procurement  artifacts. 
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4  Summary  and  Conclusions 


Software  product  lines  have  proven  to  be  one  of  the  most  innovative  and  practical 
means  to  take  advantage  of  reusable  assets  across  projects.  Data  from  industry 
clearly  demonstrates  that  a  product  line  approach  can  save  money  and  result  in 
faster  time  to  market  of  higher  quality  systems.  While  there  are  also  costs  and  risks 
for  any  product  line  program,  if  appropriately  chosen  and  properly  managed,  the 
benefits  of  a  product  line  approach  far  exceed  the  costs.  By  exploiting  strategic 
software  reuse,  a  well-managed  product  line  approach  holds  great  promise  for  the 
DoD  in  terms  of  efficiency,  time  to  field  mission  capability,  and  quality. 

The  two  essential  activities  in  the  software  product  line  practice  from  an 
acquisition  perspective  involve  the  commissioning  suppliers  or  contractors  for  core 
assets  and  commissioning  suppliers  or  contractors  for  products  constructed  from 
these  assets.  This  represents  a  new  paradigm  within  the  DoD  environment  and 
culture. 

While  it  is  evident  that  product  line  practice  calls  for  a  new  technical  approach, 
new  non-technical  and  business  practices  are  equally  crucial.  There  is  a  constant 
need  for  strong  visionary  management  to  invest  the  resources  in  the  development 
or  acquisition  of  the  core  assets  and  to  develop  the  cultural  change  to  view  new 
products  in  the  context  of  a  common  set  of  core  assets.  This  cultural  change  also 
manifests  itself  in  requiring  different  acquisition  approaches  and  different  skills  for 
the  acquisition  teams. 

Other  notes  in  this  series  will  address  some  of  the  more  significant  business  and 
acquisition  challenges  and  issues  for  transitioning  product  line  practice,  such  as: 
building  a  business  case,  measuring  the  impact  of  a  product  line  approach, 
developing  a  product  line  acquisition  strategy,  choosing  an  appropriate  funding 
model,  and  developing  a  product  line  concept  of  operations. 
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Feedback  and  Contact 


SEI  Technical  Notes  on  Acquisition  Guidelines  for  Product  Lines 

Comments  or  suggestions  about  this  first  in  a  series  of  technical  notes  on  software 
product  line  business  and  acquisition  guidelines  are  welcome.  We  want  this  series 
to  be  responsive  to  the  needs  of  DoD  and  government  personnel  involved  in  the 
business  and  acquisition  aspects  of  implementing  software  product  lines.  To  that 
end,  comments  concerning  this  technical  note,  inclusion  of  other  topics,  or  any 
other  issues  or  concerns  will  be  of  great  value  in  continuing  this  series.  Comments 
or  suggestions  should  be  sent  to 

Linda  Northrop,  Director 
Product  Line  Systems  Program 
lmn@sei.cmu.edu 


Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 
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